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REMARKS 

In view of the preceding amendments and the following comments, and pursuant to 37 
C.F.R. §1.111, Assignee respectfully requests reconsideration of the Non-Final Office Action 
mailed November 16, 2006 ("Office Action"). 

Summary 

The Office Action mailed on November 16, 2006 provided grounds for rejection of 
claims 1-21 . Assignee has amended independent claims 1, 20, and 21 , and dependent Claims 2- 
1 9. Assignee has added new dependent claims 22-30. Support for the amendments to Claims 1- 
21, and new claims 22-30 can be found in the Application at least at 0052, 0091 , 0100-0105, 
0124, 0125, and 0130. The Assignee respectfully request reconsideration of pending claims 1- 
30, and allowance of the present application in view of the following remarks. 

I. Rejections Under 35 U.S.C. § 102(b) 

The Office Action rejected claims 1, 2, 6, 8-9, 11, and 13-21 under 35 U.S.C § 102(b) as being 
anticipated by Ariathurai et al. (U.S. Patent Publication No. 2002/01 98743 Al). 

Claims 1.20. and 21 

With respect to independent claims 1, 20, and 21 , the Office Action indicates that Ariathurai 
discloses a data structure comprising: an account entity class, a customer entity class, and an 
involvement entity class. See Office Action, pp. 2, and 6. However, although Ariathurai 
discloses using a tool to "relationally store data" and "relationally organize" data, Ariathurai 
does not define a relationship between an account entity class, a customer entity class, and an 
account involvement entity class. Instead, Ariathurai merely indicates that it has a database that 
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"includes a set of related database tables which store information related to all aspects of the 
insurance underwriting process, including customer infonnation, policy information, invoice and 
billing information and accounting information." See Ariathurai at ffl 0019, 0043, 0044, 0112, 
01 14, and 0123. The Office Action fills the gap by asserting that Ariathurai inherently includes 
such features, making reference to Faithe Wempen, Sams Teach Yourself Microsoft Access 2000 
(Sams 1999). Specifically, the Office Action notes that the practice of creating account entity 
classes among plurality of account data object and one plurality of customer data objects are 
inherent and well known, [and that] Faithe made clear how to create table relationships in a 
relational database such as Microsoft Access by establishing relationship among classes or 
objects." Office Action, pp. 2-3. 

Assignee traverses this rejection since Ariathurai, even assuming that it inherently 
includes features that the Office Action sees in Faithe, does not disclose the combination of 
relationships defined by claims 1 , 20, or 21 . 

Claims 1, 20, and 21 include an entity class for establishing an account role entity that 
defines: a first account role for the first customer data object; and a second account role for the 
first customer data object different from the first account role, for establishing multiple different 
roles for a customer identified by the customer ID with respect to multiple different accounts 
identified by the account IDs. Accordingly, account roles "define the role of a customer data 
object with regard to a particular account data object. Examples of roles include insured, 
primary contact, and household member." Application at 1J 0052. In other words, a customer 
may have the account role of insured under one account, and primary contact under another 
account. The system of claim 1 provides underwriters with the ability to identify whether a 
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customer has multiple relationships with multiple accounts, regardless of the customers role, 
enabling a holistic approach to customer and account management 

Even assuming that Ariathurai inherently includes creating table relationships or other 
features from Faithe, Ariathurai still lacks the particular classes, entities, and relationships 
specified in claim 1 . In other words, given how to create table relationships, Ariathurai fails to 
disclose what table relationships to create. The number of permutations of unique 
relationships that maybe defined between any two objects is often immense and is only limited 
by the number of attributes of the objects. Ariathurai's general discussion of "a relational 
database," "relationally organized data," and "related database tables" does not disclose, for 
example, account role entities, let alone disclose the combination of relationships between 
objects that claims 1, 20 or 21 recites, nor the advantages of such relationships. 

In further contrast to claim 2 1 , as amended, Ariathurai does not provide motivation for 
defining table structures and relationships establishing multiple risk factors related to accounts, 
customer, products or services, as recited in claim 21 , "providing an entity for storing risk 
information that defines risk factors related to any one of the account data objects, the customer 
data objects, the product data objects or the service data objects, comprising: risk trends; risk 
exposures; risk assessments; and risk capacity." 

For at least the foregoing reasons, claims I, 20 and 21, and the claims dependent 
therefrom are not anticipated by Ariathurai. Thus, the presently pending claims are allowable 
over the cited references. Accordingly, Assignee respectfully requests that the claim rejections 
under 35 U.S.C. § 102Cb) be withdrawn. 
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H. Rejections Under 35 U.S.C. § 103(a) 
Claims 3 and 7 

The Office Action rejected claims 3 and 7, under 35 U.S.C. § 1 03(a), as being 
unpatentable over Ariathurai in view of Faithe. Office Action, p. 7. The Assignee respectfully 
traverses these rejections. As an initial matter the Assignee notes that for the reasons given 
above, Ariathurai does not disclose the subject matter of the base claim I, including the feature 
of assigning multiple ro tes to a customer in multiple accounts. The combination of Ariathurai 
and Faithe ("Ariatburai-Faithe combination"), made in the 103 rejection, does not fdl in the gaps 
to disclose the subject matter of claims 3 , or 7, including such roles. 

Claims 4 and 5 

The Office Action rejected claims 4 and 5, under 35 U.S.C. § 103(a), as being 
unpatentable over Ariathurai in view of Michael Hernandez, Relational Database Design, (2" d 
ed., 2003). Office Action, p. 8. Hernandez discloses guidelines for establishing a foreign key. 
Ariathurai, in combination with Hernandez ("Ariathurai-Hernandez combination"), discloses 
data structures containing entities that include attributes defined as primary keys and foreign 
keys. See Office Action, p. 8. 

Even assuming motivation to make the Ariathurai-Hernandez combination, the 
combination does not disclose the features in claim 4 or claim 5 with base claim 1, wherein 
multiple roles are assigned to a customer in multiple accounts. 
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Claims 10 and 12 

The Office Action rejected claims 10 and 12, under 35 U.S.C. § 103(a), as being 
unpatentable over Ariathurai in view of Yeh et al. U.S. Patent Application Publication No. 
2003/0149650 Al . Office Action, p. 9. 

The Office Action indicates that Ariathurai failed to explicitly disclose the data structure, 
wherein the entity class includes a role entity that defines a role for customer data objects. See 
Office Action, p. 9. However, the Office Action fills the gap by contending that Yeh discloses a 
data structure, wherein a role entity defines a role for a customer data object. Office Action, p. 9. 
Yeh recites "each account detail transaction could be stored as a row in a .. . data base table 
named for a role that owns that account." Yeh at U 0047. Ariathurai, in combination with Yeh 
("Ariathurai-Yeh combination"), discloses roles that own accounts and that a database table may 
be named for such a role. 

Assignee traverses this rejection since the Axiathurai-Yeh combination fails to teach or 
suggest establishing multiple roles for a customer in multiple accounts, without regard to account 
ownership status. Even assuming motivation to make the Ariathurai-Yeh combination, the 
combination does not disclose the features present in claims 10 and 12 with base claim 1, 
wherein multiple account roles and multiple customer roles are assigned to a customer data 
object. The features present in claims 10 and 12, for example, allow a customer role of 
"employer or employee" to be assigned to a customer data object, while the same customer data 
object maybe assigned the account role of "insured, primary contact, or household member," 
without regard to the customer data object's account ownership status. 

For at least the foregoing reasons, Ariathurai, in view of any combination of Faithe, 
Hernandez or Yeh, does not teach or suggest each and every limitation of independent claims 1, 
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20 and 21, or the claims dependent therefrom. Thus, the presently pending claims are allowable 
over the cited references. Accordingly, Assignee respectfully requests that the claim rejections 
under 35 U.S.C. § 103(a) be withdrawn. 

Conclusion 



In view of the above remarks, Assignee respectfully submits that this application is in 
condition for allowance and such action is earnestly requested. If for any reason the Application 
is not allowable, the examiner is requested to contact the Assignee's undersigned attorney at 
(312) 321-4200. 

Respectfully submitted, 




Robert D. Summerfs Jr. 
Registration No. 5^,844 
Attorney for Applicant 



BRINKS HOFER GILSON & LIONE 
CUSTOMER NO. 28164 

Telephone: (3 1 2) 32 1 -4200 
Facsimile: (312) 321-4299 
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